Typically, service providers have a large number of customers which need to be billed regularly based on their usage of services. Such services can include, but are not limited to telecommunications service providers, television service providers, power suppliers, water suppliers, application service providers, software services, etc. The billing process involves retrieving data relating to usage of the services of each customer, combining this with existing information stored relating to each customer, such as contact details and customer account balances, and supplying this information to billing systems which process the information to generate invoices, statements and the like.
The billing process typically relates to usage during a particular billing period which is a length of time determined by the service provider. Typically, the billing period is either 4 weeks or one calendar month as this is a suitable length of time which enables billing to be done in a regular manner without being too often so as to be an inconvenience to either the service provider or the customers.
As the utilities usually have a large customer base, the customer billing process requires a large amount of computer, monetary and human resources. As a result, a number of techniques are implemented during bill generation to streamline the process. For example, a plurality of groups of customers is often each allocated to one of a number of billing cycles. A billing cycle relates to a billing period, such as a 4 week period, and each billing cycle is staggered so as to fall at a different time from the other billing cycles.
For example, a first billing cycle might run from Sep. 1, 2005 to Sep. 30, 2005, then from Oct. 1, 2005 to Oct. 31, 2005, then from Nov. 1, 2004 to Nov. 30, 2004, and so on. A second billing cycle may fall on different dates. For example, the second bill cycle might run from Sep. 2, 2005 to Oct. 1, 2005, then from Oct. 2, 2005 to Nov. 1, 2005, then from Nov. 2, 2005 to Dec. 1, 2005, and so on. As many different staggered billing cycles as necessary can be used.
A billing process typically occurs on or shortly after the completion of the current billing cycle. For example, for the first billing cycle, a billing cycle run might be initiated on Sep. 29, 2004, the next on Oct. 29, 2004, the next on Nov. 29, 2004, and so on, with the resulting invoices or statements being sent to customers once the respective billing cycle run is completed. In this manner, the processing of customer records is staggered such that only a subset of all customers are processed and billed at a particular time, rather than the entire customer base.
As a further efficiency measure, a typical billing system may implement multiple billing processors which operate in parallel. During a billing cycle run, service usage information of customers relating to the particular billing period are distributed between a number of billing processor platforms. In this manner, a number of customer accounts are processed simultaneously (i.e. account of customer group A on billing processor platform X, account of customer group B on billing processor platform Y, etc.), thus speeding up the billing cycle run. Often, each customer has an associated billing cycle identifier associated therewith to facilitate the foregoing allocation.
It is important to note that there are traditionally two types of processing: ongoing processing of usage events, which occurs all the time; and end of cycle processing, which occurs once a cycle for each cycle. Such end of cycle processing is typically most efficient when performed on the relevant usage machine, where it may use a local database for faster performance.
In order to ensure that each billing processor platform can handle cycles where each customer in a particular group exhibits heavy usage, as well as end of cycle processing (which is typically heavy), a predetermined number of processors (i.e. CPU's, etc.) are included in each billing processor platform. To this end, each billing processor platform is capable of handling a “worst case scenario,” in terms of an amount of processing required for a particularly heavy billing cycle.
One inherent problem with this type of architecture is that, inevitably, some of the processors of the billing processor platforms will, from one billing cycle to another, have unused resources. This is problematic, since processing resources are very expensive.
There is thus a need for overcoming these and/or other problems associated with the prior art.